This section is intended to provide a background or context to the invention that is recited in the claims. The description herein may include concepts that could be pursued, but are not necessarily ones that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, what is described in this section is not prior art to the description and claims in this application and is not admitted to be prior art by inclusion in this section.
Location services can refer to those services which are based upon the location of a mobile device. Conventional location services (LCS) architectures can be divided into two categories, i.e., control plane architecture and user plane architecture, according to the type of communications engaged in between relevant elements. In a control plane architecture, location determination can be done according to 3rd Generation Partnership Project (3GPP) standards using embedded signaling protocols. In addition, 3GPP standards can also involve the use of a base station subsystem (BSS)-centric architecture. Other methods of location determination are based on a network subsystem (NSS)-centric architecture, although more recent 3GPP standards releases, e.g., rel4, no longer employ the NSS-centric solution. Alternatively, a user plane architecture can be characterized as an overlay solution. In other words, a data connection on a user plane between a relevant server and a terminal is used to transfer radio interface information, satellite information, and/or other information needed to determine location.
The Open Mobile Alliance (OMA) standardization organization has introduced a scheme which can be referred to as Secure User Plane Location (SUPL). As discussed in the OMA Secure User Plane Architecture Candidate Version 1.0 document which can be found at http://member.openmobilealliance.org/ftp/Public_documents/LOC/Permanent_docum ents/OMA-AD-SUPL-V1—0-20070122-C.zip and the OMA UserPlane Location Protocol Draft Version 2.0 document which can be found at http://member.openmobilealliance.org/ftp/Public_documents/LOC/Permanent_docum ents/OMA-TS-ULP-V2—0-20070220-D.zip, SUPL can utilize user plane data bearers to provide for the transferring of location information. In addition, SUPL can utilize user plane data bearers to carry positioning technology-related protocols between an SUPL enabled terminal (SET) and a network in which the SET is operational. The location information can be utilized to compute the location of a SET.
A SUPL session can be initiated either by a SET or by the network. FIG. 1 illustrates a conventional signaling sequence for a network-initiated location request. It should be noted that network initiated services are services which originate from within a SUPL network. It may also be noted that for network initiated services, a SUPL agent 100 resides in the network, where the SUPL agent 100 can refer to one or more service access points which access network resources to obtain location information. In addition, for network initiated services, a SUPL location platform (SLP) and the SET can support various functions and/or messaging, including, for example: SUPL INIT, i.e., a message used by the SLP to initiate a SUPL session with the SET, which can include session-id, positioning method, and SLP mode information; and SUPL POS INIT, i.e., a message which can be used by the SET in initiating a positioning protocol session with the SLP that can include session-id, location identifier (lid), and SET capabilities information. In addition, SUPL POS, i.e., a message which can be used between the SLP and the SET to exchange a positioning procedure that can include session-id information and positioning process messages, e.g., Radio Resource LCS Protocol (RRLP)/Radio Resource Control (RRC)/TIA-801 messages; and SUPL END, i.e., a message for ending an existing SUPL session which can include session-id information are also supported. It should be noted that the SLP is a network entity that can be responsible for SUPL service management and position determination.
As shown in FIG. 1, an SUPL agent 100 issues a Mobile Location Protocol (MLP) Standard Location Immediate Request (SLIR) message to a Home-SLP (H-SLP) 110 with which the SUPL agent 100 is associated. The H-SLP 110 can authenticate the SUPL agent 100 to determine if the SUPL agent 100 is authorized for a service it requests, based on a received client-id. In addition, based on a received ms-id, the H-SLP 110 can apply subscriber privacy against the client-id. It can also be determined whether a previously computed position which meets a requested quality of position (QoP) is available at the H-SLP 110. The H-SLP 110 can also verify that the target SET 120 is currently not SUPL roaming and supports SUPL. The H-SLP 110 can initiate a location session with the target SET 120 using the SUPL INIT message, which can be a Wireless Application Protocol (WAP) PUSH or a Short Message Service (SMS) Trigger. When the SUPL INIT message is received by the target SET 120, it can either attach itself to a packet data network if it is not attached at the time or establish a circuit switched data connection. In addition, the target SET 120 can use additional parameters to determine if the SUPL INIT message is authentic.
The target SET 120 can evaluate notification rules, follow any appropriate actions, and can check the proxy/non-proxy mode indicator to determine if the H-SLP 110 uses a proxy or non-proxy mode. If a proxy mode is used, the target SET 120 can establish a secure Internet Protocol (IP) connection to the H-SLP 110 using an SLP address that has been provisioned by the home network to the target SET 120. The target SET 120 can then send a SUPL POS INIT message to start a positioning session with the H-SLP 110. If a coarse position calculated based on information received in the SUPL POS INIT message is available that meets the required QoP, the H-SLP 110 need not engage in a SUPL POS session. Otherwise, the H-SLP 110 then calculates the position estimate based on the received positioning measurements (SET-Assisted) or the target SET 120 calculates the position estimate based on assistance obtained from the H-SLP 110 (SET-Based).
Once the position calculation is complete, the H-SLP 110 sends the SUPL END message to the target SET 120 informing it that no further positioning procedure will be started and that the location session is finished. The target SET 120 can then release the secure IP connection to the H-SLP 110 and release all resources related to that session. The H-SLP 110 then sends the position estimate back to the SUPL agent 100 by means of a MLP Standard Location Immediate Answer (SLIA) message and the H-SLP 110 can release all resources related to the session.
FIG. 2 illustrates a conventional signaling sequence for a SET-initiated location request. It should be noted that in a SET-initiated location request, a SUPL agent can reside within the SET. As shown in FIG. 2, the SUPL agent 200 issues an MLP SLIR message to a SUPL location center (SLC) 204with which the SUPL agent 200 is associated. The SLC 204 can coordinate SUPL operations and can authenticate the SUPL agent 200 and determine whether the SUPL agent 200 is authorized for the service it requests, based on the client-id received. Furthermore, based on the received ms-id, the SLC 204 can apply subscriber privacy against the client-id. If a previously computed position which meets the requested QoP is available at the SLC 204 and no notification and verification is required, the SLC 204 can send a position estimate back to the SUPL agent 200 in a MLP SLIP message. If notification and verification or notification only is required, then the SLC 204 can verify that the target SET 220 is currently not SUPL roaming and that the target SET 220 supports SUPL.
It should be noted that the SLC 204 and a SUPL positioning center (SPC) 208 may exchange information necessary to setup the SUPL POS session. The SLC 204 initiates the location session with the target SET 220 using the SUPL INIT message, which, as described above can be a WAP PUSH or an SMS Trigger. The SUPL INIT message can contain at least session-id information, an address of the SPC 208, aproxy/non-proxy mode indicator, a Key Id, a MAC and the intended positioning method. The SUPL INIT can also contain the desired QoP. If the result of the privacy check indicates that notification or verification to the target subscriber is needed, the SLC 204 can also include a notification element in the SUPL INIT message. The Key-Id corresponds to the MAC_Master_Key, which can be used to verify that the SUPL INIT message is authentic.
If the SLC 204 decides to use a previously computed position, the SUPL INIT message can indicate this in a ‘no position’ posmethod parameter value and the target SET 220 can respond with a SUPL END message carrying the results of the verification process (access granted, or access denied). If no explicit verification is required (notification only) the target SET 220 can respond with a SUPL END message and the SLC 204 can send a position estimate back to the SUPL agent 200 in a MLP SLIP message.
Furthermore, the target SET 220 can use the address provisioned by the home network to establish a secure IP connection to the SLC 204. The target SET 220 then checks the proxy/non-proxy mode indicator to determine if the H-SLP uses proxy or non-proxy mode. In the even that a non-proxy mode is used, the target SET 220 can send a SUPL AUTH REQ message to the SLC 204. The SUPL AUTH REQ message can contain session-id, key-id 2 and SET nonce information, where the key-id 2 corresponds to a PP2_SPC_Master_key to generate PSK_SPC_Key which is used for a PSK-Transport Layer Security (TLS) session between the SPC 204 and the target SET 220. The SLC 204 uses the key-id 2 and set nonce to create a key to be used for mutual SPC/SET authentication. The SLC 204 forwards the created key to the SPC 208 through internal communication and returns a SUPL AUTH RESP message to the target SET 220. The SUPL AUTH RESP message can contain the session-id.
The target SET 220 can evaluate the notification rules and follow the appropriate actions, while establishing a secure IP connection to the SPC 208 according to the received address. The target SET 220 and H-SLP 210 perform mutual authentication and the target SET 220 sends a SUPL POS INIT message to start a positioning session with the SPC 208. The SET can send the SUPL POS INIT message even if the SET supported positioning technologies do not include the intended positioning method indicated in the SUPL INIT message. The SUPL POS INIT message can contain at least a session-id, SET capabilities and lid. The target SET 220 can then provide its position, if this is supported. Otherwise, the target SET 220 can set the Requested Assistance Data element in the SUPL POS INIT message. Thereafter, the target SET 220 can release the IP connection to the SLC 204 and release all resources related to the session.
Alternatively, the SLC 204 and the SPC 208 can collaborate to determine an initial position of the target SET 220 to aid in the position determination process. If the initial position calculated based on information received in the SUPL POS INIT message meets the requested QoP, the SPC 208 can directly engage in a SUPL POS session. Based on the SUPL POS INIT message which includes the posmethod(s) supported by the target SET 220, the SPC 208 can determine the posmethod. If required for the posmethod, the SPC 208 can use the supported positioning protocol (e.g., RRLP, RRC, TIA-801) from the SUPL POS INIT message. In addition, the target SET 220 and the SPC 208 exchange several successive positioning procedure messages. The SPC 208 then calculates the position estimate based on the received positioning measurements (SET-Assisted) or the target SET 220 calculates the position estimate based on assistance obtained from the SPC 208 (SET-Based).
Once the position calculation is complete, the SPC 208 can send the SUPL END message to the target SET 220 informing it that no further positioning procedure will be started and that the SUPL session is complete, whereupon the target SET 220 can release the secure IP connection to the SPC 208 and release all resources related to the session. The SPC 208 informs the SLC 2047 about the end of the SUPL session. Unless the SLC 204 already knows the position, e.g., from a prior determination, the SPC 208 informs the SLC 204 of the determined position and the SPC 208 can release all resources related to this session. Lastly, the SLC 204 sends the position estimate back to the SUPL agent 200 an MLP SLIA message. The SLC 204 can then release all resources related to the session.
As described above in the case of network-initiated location requests, the conventional SUPL architecture sends a session initiation message, e.g., SUPL INIT message, using SMS or WAP according to the OMA SUPL standard. However, sending the session initiation message in this manner can take an inordinate amount of time. For example, an SMS message can be delayed more than thirty seconds. In addition, the mere conventional sending of SMS messages already causes a 10 second delay before session initialization can commence. Therefore, the process of session initialization can be faster through the use of alternate methods. It should be noted that references to ST2, UT2, UT3, and UT4 can refer to timers/time periods between which various signaling messages are to be sent/received.